前言

前一篇簡單介紹了 Argo Rollouts 的原理，Rollout Controller 會追蹤 Rollout 元件是否變動，並建立部署策略完成自動部署，而 Analysis Template 可以設定特定閥值(Ex: 錯誤率需低於多少)，若部署時遇到問題能夠自動 Rollback 回穩定版本。

本篇會先了解要如何撰寫 Rollout 與 Analysis Template 的 Yaml 檔案，最後會透過整合練習，了解 Istio 如何與 Argo Rollouts 整合使用。

Rollout Yaml 檔解析

使用 Argo Rollouts 時會用 Rollout 元件取代 Kubernetes 原生的 Deployment 元件。Rollout 元件除了能定義 ReplicaSet 建立所需數量的 Pods 之外，還提供了 Strategy 功能來設定要使用的部署策略、Analysis 方式以及每個 Steps 要如何執行，下面就來看看要如何定義吧！

在 rollout.yaml#L16 定義 Pod 的規格，包括要使用哪個 Image、要開啟哪些 Ports 等等資訊，此部分如同 Deployment 的 Template 部分。

    ...
    ...
    spec:
      containers:
      - name: istio-rollout
        image: argoproj/rollouts-demo:orange
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        resources:
          requests:
            memory: 32Mi
            cpu: 5m

在 rollout.yaml#L28 則定義部署策略的詳細設定，在這裡採用 Canary Deployment，analysis 欄位定義 Analysis Templates 要使用何者，而 trafficRouting 欄位則定義要使用哪個 Traffic Management Tool。

  strategy:
    canary:
      # analysis will be performed in background, while rollout is progressing through its steps
      analysis:
        startingStep: 1   # index of step list, of when to start this analysis
        templates:
        - templateName: istio-success-rate
        args:             # arguments allow AnalysisTemplates to be re-used
        - name: service 
          value: istio-rollout
        - name: namespace
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
      trafficRouting:
        istio:
          virtualService:
            name: istio-rollout-vsvc
            routes:
            - primary
          destinationRule:
            name: rollout-destrule    # required
            canarySubsetName: canary  # required
            stableSubsetName: stable  # required

• analysis
  • 使用 istio-success-rate 作為 Template 並設定好參數
• trafficRouting
  • 使用 Istio 作為 Traffic Management Tool，並設定要使用哪個 VirtualService 以及 DestinationRule

在 rollout.yaml#L52 定義部署策略的 Steps 要如何執行，以此例子來說，新版本的流量每 30 秒就會增加 10%，到 20% 時會做停頓，讓我們觀察應用程式是否正常運作，若順利即可繼續下一步 Step 逐步將流量轉移至新版本。

      steps:
      - setWeight: 10
      - pause: {duration: 30s}         
      - setWeight: 20
      - pause: {} # pause indefinitely
      - setWeight: 30
      - pause: {duration: 30s}
      - setWeight: 40
...
...

• setWeight
  • 設定新版本的流量比例
• pause
  • 設定暫停規則

Analysis Template Yaml 檔解析

在 Analysis Template 會設定 Metrics Provider 以及 successCondition 的 thresholds(閥值)，告訴系統如何蒐集 Metrics 資訊以及成功部署要達到哪些指標，並讓 Rollout 元件可以匯入此 Template。

analysis.yaml#L5 定義了 Template args 名稱、successCondition 的 Thresholds、Metrics Provider 使用何者，以及 Thresholds 的值要如何 Query。

...
...
spec:
  args:
  - name: service
  - name: namespace
  metrics:
  - name: success-rate
    initialDelay: 60s
    interval: 20s
    successCondition: result[0] > 0.90
    provider:
      prometheus:
        address: http://prometheus.istio-system:9090
        query: >+
          sum(irate(istio_requests_total{
            reporter="source",
            destination_service=~"{{args.service}}.{{args.namespace}}.svc.cluster.local",
            response_code!~"5.*"}[40s])
          )
          /
          sum(irate(istio_requests_total{
            reporter="source",
            destination_service=~"{{args.service}}.{{args.namespace}}.svc.cluster.local"}[40s])
          )

• successCondition
  • 設定 Thresholds 需大於 0.90
• provider
  • 使用 Prometheus 並提供 Address
• query
  • 使用 PromQL 語法，此為抓取正常流量與所有流量的比值。

在此 Template 的設定中，若是錯誤流量大於 10%，Query 的數值就會小於 90%，觸發警報使系統 Rollback 至穩定版本。

使用 Argo Rollouts 實現 Canary

最後就來實際操作一遍走過 Argo Rollouts 的流程，請先依照上一篇的教學準備好 Argo Rollouts 實驗環境並安裝好 Demo 程式。

首先會先 Push 版本更新的 Commit 到 Git Repo，Argo CD 會 Sync Repo 資料，將更動部署到環境並觸發部署策略，執行 Rollout 定義的 Steps 並對 Metrics 分析，決定是否需要 Rollback 或是繼續移轉流量完成部署。

Argo Rollouts 實驗架構圖，透過 Argo CD 可以將 Deploy、Operate DevOps Pipeline 用更安全的部署方式交付。

一開始使用前一章安裝的 Kubectl Plugin 查看 Rollout 的狀態。

1. 使用 kubectl argo rollouts get rollout <name> 查看 Rollout 狀態

kubectl argo rollouts get rollout istio-rollout -n rollouts-demo-istio

(輸出結果)

Status:          ✔ Healthy
Strategy:        Canary
  Step:          18/18
  SetWeight:     100
  ActualWeight:  100
Images:          argoproj/rollouts-demo:orange (stable)
...
...
NAME                                       KIND        STATUS    
⟳ istio-rollout                            Rollout     ✔ Healthy 
└──# revision:1
   └──⧉ istio-rollout-7f96d86486           ReplicaSet ✔ Healthy  
      └──□ istio-rollout-7f96d86486-ltd7p  Pod        ✔ Running  

可以看到在 rollout.yaml 定義的資訊，以及目前應用程式的狀態為何

接著準備 4 種不同的 Dashboards，利用前面所學的 Observability 工具幫助我們仔細觀察 Argo Rolloouts 的部署過程。

• 左上角為 Kubectl Plugin 的輸出結果，可以看到 Rollout 的狀態為何。
• 右上角為應用程式 UI ，每個方形方塊皆為一個 Reqest 結果。
• 左下角為 Kiali UI，可以查看應用程式的架構以及流量分佈情形。
• 右下角為 Grafana UI，建立了顯示正常流量/所有流量 thresholds 的 Panel，可觀察 Analysis 是否會觸發警報。
  

透過 Istio 的功能建立各式 Dashboards，藉此提升部署時系統的 Observability

接著我們要部署新的版本，將橘色方塊改成藍色方塊，作法就是修改 rollout.yaml 的設定並 Push 到 Github，Argo CD 就會幫我們自動 Sync 更動。

2. 修改 rollout.yaml 中 Container 的 Image Tag

# 改動前
    spec:
      containers:
      - name: istio-rollout
        image: argoproj/rollouts-demo:orange
# 改動後
    spec:
      containers:
      - name: istio-rollout
        image: argoproj/rollouts-demo:blue

3. 將改動 Commit 後 Push 到 Github

git add .
git commit -m "update to blue version"
gut push origin main

此時因為 Rollout Controller 偵測到 Rollout 元件的更動，會自動觸發部署策略以 Canary 形式部署。

Step1 時的狀態，有 10% 流量轉移到新版本，可以從 Logs 輸出以及應用程式 UI 介面觀察到

在 Step3 時會先暫停流量轉移，讓維運人員可以先觀察小部分的流量更新有無系統異常，在這裡藉由應用程式提供的 ERROR 功能主動製造異常，看系統會如何反應。

3. 在應用程式 UI 設定 ERROR 比例並點擊 START

Step3 時的狀態，有 20% 流量轉移到新版本，在 Kiali UI 也能觀察流量變化情形

系統開始出現異常(紅框方塊)後，若正常流量比例小於 0.9，Argo Rollout 就會將系統 Rollback 至前一個版本。

從 Grafana 介面可看到正常流量比小於 0.9，觸發了 Analysis Template 設定的 Thresholds，系統會退回至前一個版本

總結

本篇算是將前面所學的概念利用 Argo Rollouts 專案做一個統整練習，但文章的形式很難寫出部署過程中的所有細節，想要仔細了解的讀者可以先觀看官方提供的影片，再搭配此文章應該就能了解整個流程了。